Method and system for displaying translation information

ABSTRACT

An interactive translation system ( 10 ) includes a front end ( 40 ), a back end ( 42 ), and a user interface ( 16 ). The front end ( 40 ) is operable to identify source elements ( 86 ) in a source file ( 24 ). The back end ( 42 ) is operable to generate a translation file having translation elements corresponding to translation of said identified source elements ( 86 ) and having an interface ( 16 ) for receiving inputs for modifying said translation.

TECHNICAL FIELD OF THE INVENTION

[0001] This invention relates generally to translation systems forcomputer programs, and more particularly to an interactive translationsystem and method.

BACKGROUND OF THE INVENTION

[0002] A digital signal processor (DSP) is a computer chip adapted for aparticular purpose. DSPs are used to electronically process digitizedanalogue or digital signals. The signals may be voice, data, radio, orother similar signals. DSPs are often found in telephony systems, radiosystems, CD players, computers, and TVs.

[0003] DSPs are typically programmed using assembly language. Assemblylanguage is used because it allows for the creation of highly optimizedprograms for the DSP. Assembly language may also be used because of alack of tools, such as compilers, available for the DSP. As new DSPchips replace older DSP chips, the assembly language used on the new DSPchips is often different from the assembly language used on the old DSPchips. Thus, in order to utilize new DSP chips, assembly languageprograms for old DSP chips must be rewritten for new DSP chips.

[0004] Rewriting an assembly language program from an old DSP chip towork on a new DSP chip is a tedious, time consuming and difficultprocess. Typically, the rewriting is done manually, with the programmerstarting from scratch and writing the entire program for the new DSPchip, or by using simple tools, or by using simulators that run the oldDSP program on the new DSP chip. These methods are problematic becausethey are slow and prone to inaccuracies or inefficiencies.

SUMMARY OF THE INVENTION

[0005] In accordance with the present invention, an interactivetranslation system and method are provided that substantially eliminateor reduce disadvantages and problems associated with previouslydeveloped translation or migration systems and methods. In particular,the interactive translation system and method combine static translationwith an interactive environment in order to provide both accurate andefficient translations with minimal user intervention.

[0006] In one embodiment of the present invention, an interactivetranslation system includes a front end, a back end, and a userinterface. The front end is operable to identify source elements in asource file. The back end is operable to generate a translation filehaving translation elements corresponding to translation of theidentified source elements and having an interface for receiving inputsfor modifying the translation.

[0007] More specifically, in accordance with one embodiment of thepresent invention, the source and translation files are assemblylanguage files. In this and other embodiments, the source and thetranslation files may be for disparate source and target devices ordisparate formats for a same device.

[0008] In another embodiment, a method for performing translation isprovided. The method receives a source file and identifies sourceelements in the source file. The method generates a translation filehaving translation elements for a target device by performing acontext-dependent translation of the source elements. The methoddisplays the translation elements in an interface for receiving userinputs and in response to user inputs automatically regenerates selectedtranslation elements based on the user input.

[0009] Technical advantages of the present invention include providingan improved translation system and method. In particular, thetranslation system and method combine static analysis of a sourceprogram with an interactive environment that prompts a user forinformation about the source program that is not staticallydeterminable. The static analysis provides for efficient translationwhile the interactive environment provides information not availablefrom static analysis. In this way, the translation is both accurate andefficient.

[0010] Other technical advantages will be readily apparent to oneskilled in the art from the following figures, description, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For a more complete understanding of the present invention andits advantages, reference is now made to the following description takenin conjunction with the accompanying drawings in which:

[0012]FIG. 1 is a block diagram illustrating a translation system inaccordance with one embodiment of the present invention;

[0013]FIG. 2 is a high-level flow diagram illustrating an operation ofthe translation system of FIG. 1;

[0014]FIG. 3 is a screen display illustrating details of a graphicaluser interface for the translation system of FIG. 1;

[0015]FIG. 4 is a screen display illustrating a translation wizard forthe graphical user interface of FIG. 3;

[0016]FIG. 5 is a flow diagram illustrating a method for convertingsource elements into translation elements using pattern matching in thetranslator of the translation system of FIG. 1;

[0017]FIG. 6 is an exemplary diagram illustrating a high-level patternmatching of instructions in accordance with the method of FIG. 5;

[0018]FIG. 7 is an exemplary diagram illustrating a low-level patternmatching of operands in accordance with the method of FIG. 5;

[0019]FIG. 8 is a flow diagram illustrating a method for transformingloops for translation in the transformer of the translation system ofFIG. 1;

[0020]FIG. 9 is a flow diagram illustrating a method for loopidentification for the method of FIG. 8;

[0021]FIG. 10 is an exemplary diagram illustrating loop identificationin accordance with the method of FIG. 9;

[0022]FIG. 11 is a flow diagram illustrating a method for eliminatingregisters by loop rotation for the method of FIG. 8;

[0023]FIG. 12 is an exemplary diagram illustrating loop rotation inaccordance with the method of FIG. 11;

[0024]FIG. 13 is a flow diagram illustrating a method for loop peelingfor the method of FIG. 8;

[0025]FIG. 14 is an exemplary diagram illustrating the transformation ofloop elements in accordance with the method of FIG. 8;

[0026]FIG. 15 is a block diagram illustrating details of the source andtranslation files in the display processor for the translation system ofFIG. 1;

[0027] FIGS. 16-18 are block diagrams illustrating details of thedisplay processor for the source and translation files;

[0028]FIGS. 19A and B are a flow diagram illustrating a method forgenerating a translation display in the display processor; and

[0029]FIG. 20 is a flow diagram illustrating a method for translatinginclude files for the translation system of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

[0030]FIG. 1 illustrates a translation system 10 in accordance with oneembodiment of the present invention. As described in more detail below,the translation system 10 combines static analysis of a source file withan interactive environment that prompts a user for information about thesource file that is not statically determinable from the source file. Inthis way, both an efficient and accurate translation of the source fileis provided.

[0031] Referring to FIG. 1, the translation system 10 includes a datastorage 12, a translation tool 14, and a graphical user interface (GUI)16. The data storage 12, translation tool 14, and graphical userinterface 16 may reside on a single computer system or a distributedcomputer system. The computers may each be a personal computer, fileserver, work station, minicomputer, mainframe, or any other suitabledevice capable of processing information based on programminginstructions. In a distributed embodiment, the data storage 12,translation tool 14, and graphical user interface 16 may be connected bya local area network (LAN) such as an Intranet, a wide area network(WAN) such as the Internet, or other suitable network.

[0032] The data storage 12, the translation tool 14, and the graphicaluser interface 16 include computer software and data that are loadedinto system memory and executed by a microprocessor. The graphical userinterface 16 is displayed on a terminal 18 that includes a processor andsoftware, a keyboard, a monitor, and other suitable equipment to permitthe user to enter data and changes. The computer software and data aregenerally identified by modules, interfaces, files, and the like thatare stored and/or loaded into memory for processing. It will beunderstood that the computer software and data may be otherwise combinedand/or divided for processing without departing from the scope of thepresent invention. Accordingly, the labels of the modules, interfaces,and files are for illustrative purposes and may be suitably varied. Thecomputer software and files may when needed, be loaded into memory fromdisk storage (not shown). Disk storage may include a variety of types ofstorage media such as, for example, floppy disk drives, hard diskdrives, CD-ROM drives, or magnetic tape drives. System memory mayinclude one or more memory devices such as RAM, ROM, disk storage, andthe like.

[0033] The data storage 12 includes data files 20 and tool resourcefiles 22. Generally described, the data files 20 include source files24, 26 that are processed by the translation tool 14 to generatetranslation files 24, 26. The tool resource files 22 include files usedby the translation tool in processing the data files 20 that may bebuilt into the tool 14 or separately loaded when needed.

[0034] The data files 20 include a source file 24, one or more sourceinclude files 26, a translation file 28, and one or more translationinclude files 30. The source file 24 includes a plurality of sourceelements that define operations of a source device. The source elementsinclude source instructions, comments, directives, and the like. Aninstruction is an atomic command capable of being executed on aprocessing device, representing an operation to be performed. Itincludes an opcode, which specifies the operation to be performed, andoperands, which specify objects on which the operation is to beperformed. Comments are non-executable code that typically provideinformation about the purpose, effect, or use of instructions, set ofinstructions, file structure, and the like. Directives arenon-executable statements that modify the interpretation of theinstructions.

[0035] The source include files 26 are each called by the source file 24to perform a predefined operation or set of operations. As used herein,each means each of at least a subset of the identified items. Theinclude file 26 typically includes code to perform (or performs) anoperation used by a number of files and is therefore most efficientlyprogrammed as a separate file that can be used or called by any numberof source files 24.

[0036] The translation file 28 is a translation of the source file 24.The translation file 28 includes translation elements that correspond tothe source elements. A translation element or group of translationelements corresponds to a source element when it is translated,converted, or derived from or otherwise based upon a source element orgroup of source elements. The translation elements include instructions,comments, directives, and the like.

[0037] The translation include files 30 are each a translation of asource include file 26. The translation include files 30 are called bythe translation file 28 the same way or in a similar way in which thesource include files 26 are called by the source file 24.

[0038] The tool resource files 22 include a source machine description32, a target machine description 34, a translation machine description36, and oracle files 38. As described in more detail below, the toolresource files 22 are used by the translation tool 14 to translate thesource file 24 and any source include files 26 into the translation file28 and the translation include files 30.

[0039] The source machine description 32 is a model of the sourcedevice. The target machine description 34 is a model of the targetdevice. In one embodiment, as described in more detail below, the modelseach describe the registers and the instructions and addressing modes oftheir associated device using abstractions that are independent of thedevice being described. The addressing modes are a means of specifyingthe operands in an instruction for a device. Thus, the source machinedescription 32 defines instructions and operands for the source device.The target machine description 34 defines instructions and operands forthe target device. The source and target machine descriptions 32 and 34are modular in that each is used anytime a file is to be translated fromor to their corresponding device; that is, a machine description may beused as a source or target machine description.

[0040] The translation machine description 36 provides translationbetween the source and target machine descriptions 32 and 34. Asdescribed in more detail below, the translation machine description 36maps instructions and their associated operands from the source files 24and 26 to the translation files 28 and 30. The translation machinedescription 36 is a specially designed model that describes thetranslation between specific source and target machine description files32 and 34.

[0041] The oracle files 38 provide for customization of the translationtool 14. The oracle files 38 are used to describe device characteristicsnot modeled by the machine descriptions 32, 34, and 36. In oneembodiment, the oracle files are device dependent. In this and otherembodiments, an oracle file 38 may be loaded and used by the analyzer,translator, transformer, or display processor of the translation tool 14to aid translation.

[0042] In one embodiment of the present invention, the translationsystem 10 translates between assembly language files. In thisembodiment, the source and translation files 24, 26, 28, and 30 areassembly language files. The machine description and oracle files 32,34, 36, and 38 are preferably models represented in some high-levellanguage or in some language specifically designed for modeling aprocessor. Preferably, they are compiled and linked into the tool 14,although clearly they may also be separately loaded. Assembly languageis a programming language in which there is generally a one-to-onecorrespondence between statements expressed in the language andexecutable instructions of a processing device. Assembly language isused for programming digital signal processors (DSP) and other suitabledevices.

[0043] In the assembly language embodiment, the translation system 10may convert an assembly language file for one device into an assemblylanguage file for another device or convert a linear assembly languagefile into a scheduled assembly language file for a same or differentdevice. A linear assembly language is a programming language in whichthere is a one-to-one correspondence between statements expressed in thelanguage and executable instructions of an abstract processing device.The instructions of the abstract device represent those of an actualdevice, except in the abstract device all of the operations representedby any given instruction are completed before any of those for asubsequent instruction. Scheduled assembly language is an assemblylanguage for an actual device, in which the execution of theinstructions may overlap in such a way that some or all of theoperations represented by any given instruction may not complete beforethose of a subsequent instruction. The translation system 10 may be usedto convert other low-level or suitable programming files from operationon a first device to operation on a second device or from a first formatto a second format for a same or different device.

[0044] Thus, the present invention provides a translation system using acomputer capable of executing a program and an interactive program fortranslating code for a first processor into code for a second processorand capable of being executed on the computer.

[0045] The translation tool 14 includes a front end 40 and a back end42. Generally described, the front end 40 performs preprocessingfunctions that convert data and information into internalrepresentations that can be conveniently processed by the back end 42 orother part of the translation tool 14. The front and back ends 40 and 42may be part of a same program, each be a separate program, set ofprograms, or part of one or more programs, partially combined andseparated between any number of programs, and the like.

[0046] The front end 40 is operable to identify instructions and othersource elements in the source file 24. In one embodiment, the front end40 includes a parser that steps through the source file 24 and generatesa list of discrete source elements. As previously described, theelements include instructions, directives, and comments of the sourcefile 24. The discrete elements are passed to the back end 42 fortranslation and other suitable action. In one embodiment, the front end40 is further operable to reorder the source elements into logicalsections of related elements for internal analysis and processing. Inthis embodiment, the discrete elements are passed to the back end 42 andprocessed as a logical section. A section is a logical sequence ofinstructions that form an independent thread of processing and maycontain calls or branches, but remains coherent during loading andexecution of the source file. After processing, the elements arereturned to original source order for display to a user.

[0047] In one embodiment, the back end 42 includes an analyzer 44, atranslator 46, a transformer 48, and a display processor 50. Theanalyzer 44 analyzes the source elements and divides them into basicblocks. A basic block is a maximal length sequence of code whereexecution (control) only enters from the beginning of the sequence andonly exits from the end of the sequence. The analyzer 44 also receivesuser input via the graphical user interface 16 and reanalyzes the sourceelements in response to any user input. The analyzer 44 passes theresults of its analysis to the translator 46. One analysis is to trackvalues in source registers to determine their value when the sourceprogram executes. Another analysis determines lifetimes of registersaccessed in source elements.

[0048] The translator 46 translates the source elements identified bythe analyzer 44 into translation elements. As described in more detailbelow, the translator 46 utilizes the source, target, and translationmachine descriptions 32, 34, and 36 to match instructional and operandpatterns between the source and target devices. In this way, thetranslator 46 efficiently maps source instructions to translationinstructions without the need for customized coding for the source andtarget devices. The translator 46 generates an initial translation thatis passed to the transformer 48 for further processing and communicateswith the graphical user interface 16 via messages.

[0049] The transformer 48 provides fix-ups and optimization for theinitial translation generated by the translator 46. As described in moredetail below, for example, the transformer 48 identifies and manipulatesloops to aid the translation process. The transformer 48 also allocatesregisters to temporary variables introduced by the translation andschedules translation instructions for the target processor. Thetransformer 48 passes an intermediate translation including the fix-upsand optimization to the display processor 50. The transformer 48 alsocommunicates with the graphical user interface 16 via messages.

[0050] The display processor 50 receives the source file and the initialand the intermediate translations and generates a display of the sourceand translation files that is output to the graphical user interface 16.As used herein, identified files, data, and information include thosefiles, data, or information, any representations of or based on thosefiles, data, or information, and any previous or subsequent forms ofthose files, data, or information.

[0051] In one embodiment, as described in more detail below, the displayprocessor 50 builds a display in which corresponding groups of elementsin the source and translation files are aligned, in which source andcorresponding translation instructions are associated with each other,and in which the source and translation files are displayedside-by-side. The display is passed to the graphical user interface 16for display to the user.

[0052] The graphical user interface 16 displays the source andtranslation files to the user for review and modification. The graphicaluser interface 16 passes user modification back to the translation tool14 for reanalysis, retranslation, and other appropriate action. The usermodifications include any user input operable to modify the translation,the translation process, and the like. Once the user is satisfied withthe translation, the then existing intermediate translation is saved asthe translation file 28.

[0053]FIG. 2 is a high-level flow diagram illustrating operation of thetranslation system 10 in accordance with one embodiment of the presentinvention. It will be understood that the translation process mayinclude other or different operations in the same or a different order.

[0054] Referring to FIG. 2, the source file 24 is received by thetranslation tool 14 at step 52. Next, at step 54, the source and targetdevices are identified for or by the translation tool 14. The source andtarget devices may be identified by a user or based on other informationprovided to the translation tool 14. Proceeding to step 56, thetranslation tool 14 loads the source, target, and translation machinedescriptions 32, 34, and 36 for the source and target devices. Anyoracle files 38 for a target or source for the translation tool 14 areloaded at step 58.

[0055] At step 60, the front end 40 of the translation tool 14identifies source elements in the source file 24. The source elementsare statically analyzed by the analyzer 44 at step 62. Next, at step 64,a translation file is generated having translation elements byperforming context-dependent translation of the source elements. Thetranslation is performed by the translator 46 with fix-ups andoptimizations performed by the transformer 48.

[0056] Proceeding to step 66, a screen display of the source andtranslation files is generated by the display processor 50 of thetranslation tool 14. Next, at state 68, the source and translation filesare displayed by the graphical user interface 16 for review andmodification by the user. In response to user modifications received bythe graphical user interface 16, state 68 returns to step 62 in whichthe source elements are reanalyzed and retranslated based on the usermodification.

[0057] After the user is satisfied with the translation, state 68 leadsto step 70 in which the intermediate translation file being reviewed bythe user is saved as the final translation file 28. Step 70 leads to theend of the process. Accordingly, the translation tool 14 automaticallytranslates the source file 24 based on a static analysis and displaysthe translation to the user for review and modification. As used herein,an event is automatic in that the event is predefined and carried out bythe computer process. The event may be immediate or in response to auser action or other suitable event. In this way, the source file 24 isefficiently and accurately translated into the translation file 28.

[0058]FIG. 3 is a screen display illustrating one embodiment of thegraphical user interface 16. As described in more detail below, thegraphical user interface 16 provides an intuitive interface for the userto review, modify, and save a translation 28, 30.

[0059] Referring to FIG. 3, the graphical user interface 16 includessoftware programs operating on the monitor, a graphical interface window72 having a source window 74, a translation window 76, and an outputwindow 78. The graphical interface window 72 includes a menu bar 80 witha variety of pull down menus disposed along the top edge of the window72. A toolbar 82 is disposed immediately below the menu bar 80. A statusbar 84 is disposed along the bottom edge of the window 72.

[0060] Using the menu bar 80 or other commands, the user may specifycertain global information that can be used by the translation process.For example, a user may specify a compatibility mode, assumptions aboutstatus bits, and register liveness at entry points, at exit points, andat function call sites. This information is used each time a particulartranslation issue is encountered, reducing the need for userinteraction.

[0061] The toolbar 82 includes a plurality of arrow icons that allow theuser to quickly traverse through errors or other issues within thesource and translation windows 74 and 76. In one embodiment, the arrowsmay traverse the user to the first, previous, next, and last error orissue for a translation.

[0062] The source window 74 displays the source elements 86 he while thetranslation window 76 displays the translation elements 88. For theembodiment of FIG. 3, the source and translation windows 74 and 76 aredisplayed side-by-side to allow simultaneous viewing of the source andtranslation elements 86 and 88 by the user. In addition, correspondinggroups of elements 90 are aligned in the source and display windows 74and 76 to allow simultaneous viewing of source elements 86 and theirtranslations 88. Synchronized scroll bars 92 are provided for thewindows 74 and 76 to maintain alignment during any review andmodification by the user. In response to a user selection of an element,the corresponding source and translation elements 94 are highlighted.Thus, the user is immediately informed of the translation correspondingto any source element 86. Similarly, a translation element 88 may beimmediately identified with its source element 86.

[0063] The graphical user interface 16 marks problematic or otherelements for which review or additional information is indicated in oneof the source and translation windows 74 and 76 with a status icon 96.In one embodiment, the source window 74 icons include a red octagon foran error situation, a yellow diamond for a warning situation, a greensquare for an efficiency situation, and a green arrow for a linkagesituation, all as depicted in FIG. 3. In this embodiment, the redoctagon indicates an error situation where the translation is known tobe incorrect, impossible, or beyond the limits of the translator 14. Theuser is prompted to supply information to allow a correct translation tobe produced. The yellow diamond icon indicates a warning situation wherethe translation is probably correct, but depends on a particularassumption. The user may confirm or deny the assumption. The greensquare indicates an efficiency situation where the translation iscorrect, but could be improved with additional information. The user isprompted to provide the information to improve efficiency of thetranslation. Such information may be “global” in the sense that it iseffective for the entire translation and not just for an identifiedsource or target element. The green arrow indicates a linkage pointsituation, such as a call or branch, where the translation depends onwhether one or more registers are live at a particular point in thefile. A register is live if it currently contains a value that willsubsequently be used in another instruction. It will be understood thatother or different status icons 96 may be used by the translation systemto prompt the user for information that is needed or would improvetranslation.

[0064] The output window 78 contains a listing of error or issue lines98 to be reviewed and/or resolved by the user. This separate listingallows the user to quickly determine the number and type of issues to beresolved. Each listing 98 in the output window 78 provides a source linenumber and a description of the error or issue to be resolved. Clickingon the error or issue line 98 will allow the user to move the display tothe appropriate place in the source and translation windows 74 and 76.

[0065]FIG. 4 illustrates a translation wizard 100 for assisting the userin resolving translation errors or issues. Referring to FIG. 4, thetranslation wizard 100 provides a dialog box that explains a selectedtranslation issue with the line in question and allows the user torespond with information and guidance to the translator. Accordingly, auser is assisted with translation errors or issues to maximizetranslation efficiency while ensuring that the translation is accurate.Quantifications to a translation or additional information to aid thetranslation process is passed by the graphical user interface 16 back tothe translation tool 14 where the translation is regenerated based onthe user input. Accordingly, the translation is continually updatedduring interaction with the user. After the translation is completed,the user saves the translation as the translation file 28. Thetranslation file 28 may then be loaded onto the target device foroperation.

[0066] The actual translation between a source code and a target coderequires the interpretation of a source command set into a translationcommand set. Any given computer language, including assembly language,includes a set of operation commands, often called opcodes. An exampleof an opcode is MULT which is a command to multiply. Different opcodesmay exist between one set of assembly language instructions and anotherset of assembly language instructions. This means that for a givenassembly language, its opcodes may differ from the target's assemblylanguage opcodes. Indeed, one opcode in a source assembly language maytranslate to many different opcodes in a target assembly language.Alternatively, many source assembly language opcodes may translate to asingle target assembly language opcode, or there may be a many-to-manyrelationship between source and target opcodes. Associated with eachopcode, in general, is a corresponding operand. An operand is theargument (or arguments) to the opcode. For example, given an opcode ofMULT, it may have the operand of (a, b). The entire instruction wouldthus be MULT (a, b) which would mean multiply the contents of register awith the contents of register b. Where an opcode is a specific operationto be performed, the operand specifies objects on which the operation isto be performed. A given opcode may have several different operands thatcan be associated with the one opcode depending upon the use of theopcode. The combination of opcode and operand forms an instruction. Thediffering opcodes and operands between a source and target machinemotivates a translation device capable of translating efficientlybetween a source code and a target code.

[0067]FIG. 5 is a flow diagram illustrating a method for convertingsource elements into translation elements using pattern matching in thetranslator 46 of the translation system of FIG. 1. In step 120, the nextsource code instruction is read. The source code instruction in thesource file 24 or include file 26 is read by front end 40 and analyzedby translator 46 in back end 42. As discussed previously, source machinedescription 32 models the source device. That is, source machinedescription 32 contains rules that map its operands into a deviceindependent expression representation. Additionally, source machinedescription 32 contains a listing of all source opcodes. Target machinedescription 34 includes rules that map the device independentexpressions into its operands and a listing of all target opcodes.Translation machine description 36 contains a listing of all sourceopcodes and a listing of all target opcodes. The lists are associatedwith each other such that a source opcode is associated with itscorresponding target opcode. As discussed previously, one sourceinstruction could correspond to one or many target instructions, or viceversa.

[0068] After reading in the instruction in the front end 40 in step 120,in step 122 the maximum length of a possible translation set for thatinstruction is selected from the translation machine description 36 bytranslator 46. Since more than one source opcode could translate as aset to one or more target opcodes, it is necessary to know the maximumlength of a set of opcodes which begins with the opcode in theinstruction read at step 120. Then, translator 46 initially reads aheadthe number of opcodes in the source code corresponding to the maximumset length and compares that set of opcodes against possible targetopcodes using the opcode translation rules from the translation machinedescription. This is the pattern matching aspect of the presentinvention. Next, at step 124 the source opcodes in the current set arecompared to potential target opcodes. In cases where there arepotentially many target opcodes associated with one source opcode, thematching step 124 would return all possible matching opcodes. Proceedingto decisional step 126, if a match exists, the Yes branch of decisionalstep 126 leads to step 132.

[0069] At step 132 the operand associated with the source opcode isexamined to determine if there is a match between that operand and thetarget code operands for the potential target opcodes. In this case, thepattern matching is done by locating the expression tree representationof the source operand in the source machine description 32 andattempting to match the source expression tree representation to thetarget expression tree representation from the target machinedescription 34, which may include a number of operands for the opcode.Then, at decisional step 134, if a match exists, the Yes branch ofdecisional step 134 leads to step 138. At step 138, the targetinstruction including the matching opcode and operand is saved as thetranslation for the source instruction.

[0070] After the current instruction or instruction set has beentranslated, at decisional step 140 it is determined if the currentinstruction is the last instruction in the source file 24. If theinstruction is the last instruction in the source file, the Yes branchof decisional step 140 leads to the end of the process, and translationis complete. If additional instructions remain to be translated in thesource file 24, the No branch of decisional step 140 returns to step 120in which the next instruction is read and then translated as previouslydescribed.

[0071] Returning to decisional step 126, if there is no match ofopcodes, the No branch of decisional step 126 leads to decisional step135. At decisional step 135, it is determined if the current set ofopcodes is the shortest possible length for a set of opcodes for theinstruction read at step 120. If the current set of opcodes is not ofthe shortest possible length, the No branch of decisional step 135 leadsto step 136. At step 136, a next shortest length set of opcodes, whichbegins with the current opcode read in at step 120, is selected forcomparison at step 124.

[0072] Returning to decisional step 135, if the current set of opcodesis of the shortest possible length for a set which begins with thecurrent opcode, then there is no match for the current opcode on thetranslation machine, and the instruction including the opcode isuntranslatable with current information. Accordingly, if the current setof opcodes is of the shortest possible length, the Yes branch ofdecisional step 135 leads to step 137. At step 137, the instruction readat step 120 is marked as untranslatable. Step 137 leads to decisionalstep 140 in which the process is repeated for any additionalinstructions in the source file 24.

[0073] Returning to decisional step 134, if a match does not existbetween the source code operand and any target code operands for thepotential target opcode, then the potential target opcode is not a validtranslation. Accordingly, the current set of opcodes has no validtranslation, and the No branch of decisional step 134 leads todecisional step 135 in which it is determined if a different opcode setis available for translation of the current opcode associated with theinstruction read at step 120.

[0074]FIG. 6 is an exemplary diagram illustrating a high-level patternmatching of instructions in accordance with the method of FIG. 5. As canbe seen, the one ADD opcode from the source instruction can betranslated into one of several different target opcodes, such as ADDM,ADDK, and ADDI. The selection of which is the correct target opcode isdetermined by what operand is associated with the source operand code inthe source instruction. In the present invention, when the source opcodeis compared to the target opcodes as listed in machine languagedescription 36, all possible ADD's of the target code are selected aspotential matches. The correct opcode is then determined by matchingoperands, as discussed above.

[0075] Also illustrated is how two opcodes, MULT and ADD, in the sourceopcodes can translate to a single opcode MAC in the translation. Thepresent invention uses an iterative process to determine if relatedcommands can be translated in to a single command on the translationmachine. When translating a command such as MULT, the translator checkstranslation machine description 36 to see what is the largest number ofsource opcodes that could possibly translate to a target opcode.Assuming that the number is two, translator 46 looks ahead one moreinstruction to see if the combination of MULT and the next instructionmatches a target opcode. If the next command is ADD, then the sourceopcodes of MULT and ADD would translate to the target opcode of MAC. Ifthe next opcode was not ADD, then the next shortest match length, which,in this case is one, would be employed. This means translator 46 doesnot read ahead and the opcode MULT is matched with a target opcode MULT.

[0076]FIG. 7 is an exemplary diagram illustrating a low-level patternmatching of operands in accordance with the method of FIG. 5. A sourceoperand, such as *str(k), can be converted into a device independentexpression or representation. In one embodiment, the expression orrepresentation can be what is commonly known as an expression tree. Anexpression tree breaks down an operand into basic components. As can beseen the first level of this expression tree 148 shows a star indicatingdirect addressing. Next, a plus sign representative of a positive offsetis seen followed by REG for register and CONST for constant. This meansthe operand is an indirect offset of a register by a constant. Thesource operand is mapped to an expression tree based upon the rules inthe source machine description and thus, operands, expressions andopcodes are described in source machine description 32. Similarly, theexpression tree is mapped to a related target opcode based upon therules in the target machine description and thus, operands, expressionsand opcodes are described in target machine description 34.

[0077] Sometimes when translating codes between architectures the sourcecode may use registers that do not exist in the target machine (e.g.nontranslatable registers). Special techniques can be used tosuccessfully translate a source code under certain conditions. If thelifetime of a given register can be isolated to a single basic block,the translator may be able to translate instructions involving thatregister, even though the target machine has no such register. Thelifetime of a register is the segment of an execution path of the codethat starts from a definition of the register (e.g. an instructionwrites a value into that register) and ends with the last use of theregister (e.g. an instruction reads the value from that register) Abasic block is the maximal sequence of code where execution only entersat the beginning and exits at the end (no branching in or out).

[0078]FIG. 8 is a flow diagram illustrating a method for eliminatingregisters in loops for translation in accordance with the teachings ofthe present invention. The method begins at step 160 in which the nextblock of the source code with a live register at the exit is reviewed.In step 162 block structure is examined to see if it is a loopstructure. A full discussion of loop structure determination isdiscussed below in conjunction with FIG. 9. At decisional step 162, ifthe block is not a proper loop structure, the No branch leads todecisional step 180 where it is determined if there is any more sourcecode to examine. If there is any remaining code to examine, the Yesbranch of decisional step 180 returns to step 160 and execution startsagain for a next block. If no code remains to be examined, executionends.

[0079] Returning to decisional step 164, if a proper loop structureexists, the Yes branch leads to step 166. At step 166, it is determinedif the use of the register after exit from the loop is the same as inthe loop. If so, the Yes branch of decisional step 168 leads to step 176at which loop rotation (or “hoist”) is performed. Loop rotation isfurther discussed below in conjunction with FIG. 11. If the register isnot the same, the No branch of decisional step 168 leads to step 170 inwhich the block is checked to see if it is a candidate for a peeliteration. In order for a peel iteration to be performed, there mustonly be a single entry and exit into a loop, there is no use of theregister after exit from a loop, the loop count must be staticallydeterminable and the loop count must be able to be decreased by one loopiteration. If all four criteria are fulfilled, then the Yes branch ofdecisional step 172 leads to step 174 at which a peel iteration isperformed followed by a loop rotation in step 176. Then, executionreaches step 180 where it is determined if there is any more code toreview as discussed before. Returning to decisional step 172, if thefour criteria are not met, then the No branch of decisional step 172also leads to step 180.

[0080]FIG. 9 is a flow diagram illustrating a method for identifyingloops in accordance with the teachings of the method of FIG. 8. In step190, a block of source code is received where the register is active atthe exit of a loop. This is known as an active block. In step 192, a setof all successors for the active block is determined. A successor blockis a block that has the flow of the original block directly enter thesuccessor block. Next, in step 194, a set of predecessor blocks to theactive blocks are determined. A predecessor block is a block that has anexecution flow from it to the active block.

[0081] In step 196, the successor blocks to the predecessor block arelocated. A second set of predecessors to the second set of successorsare determined in step 198. In step 200, if the set of the firstpredecessors from step 194 are different from the set of the secondpredecessors determined in step 198, then the flow structure is notsuited for loop rotation, which is an optimization for the translation.If the set of the first predecessors are the same as the set of thesecond predecessor, then loop rotation, discussed further in FIG. 10,can be used.

[0082]FIG. 10 is an exemplary diagram illustrating the identification ofa loop. Illustrated are four blocks of code. In first block 202 avariable is defined. In second block 204 a use of that variable isdefined. In third block 206 the variable is defined again, and anotheruse of the variable is found in fourth block 208. Each block mayrepresent one or more lines of a source code, but each are a basicblock. There is a loop from third block 206 to second block 204 for afixed number of iterations. First block 202 is also known as apre-header block, second block 204 is also known as a header block,third block 206 is also known as a tail block and fourth block 208 isalso known as a post-tail block. Using the method outlined inconjunction with FIG. 9, we can denote first block 202 as the firstactive block by labeling in Bph. Thus Bph={first block 202}. Thesuccessor of Bph is second block 204. Thus S₁={second block 204}. Theset of all predecessors to successor second block 204 is first block 202and third block 206 since both can lead to second block 204 (first block202 directly and third block 206 via the loop). Thus, P₁=[first block202, third block 206}. The successor to these predecessors are secondblock 204 and fourth block 208. Thus S₂={second block 204, fourth block208}. Finally, the predecessors to these successors are first block 202and third block 206. Thus P₂={first block 202, third block 206}. Now,both sets of predecessor are examined. Since P₁ and P₂ are identicalsets the structure shown in FIG. 10 can be used with loop rotation asdescribed in conjunction with FIG. 11.

[0083]FIG. 11 is a flow diagram illustrating a method for eliminatingregisters by loop rotation. In a first step 210 a proper segment of codeis received. Next, in step 212 use of the register inside of the loopstructure 204 is combined with the definition of the register outsidethe loop structure 202. The use of the register outside the loopstructure 208 is combined with the definition of the register inside theloop structure 206 in step 214. This removes the lifetime of theregister between the block outside of the loop 208 and the block insidethe loop 206, between the last block in the loop 206 and the blockoutside the loop 208 and the last block in the loop 206 and the firstblock in the loop 204.

[0084]FIG. 12 illustrates loop rotation in accordance with the method ofFIG. 11 applied to the loop of FIG. 10. Illustrated is a first block 202also known as a pre-header block where the register variable is defined.A second block 204, also known as a header block, uses the registervariable. A third block 206, known as a tail block, defines the use ofthe register variable again. First block 202, the header block, andthird block 206, the tail block, comprise the loop structure which goesfrom the output of the tail block, along back edge 205 to the headerblock. Typically, looping will occur for a set number of iterations. Afourth block 208, also known as the post-tail block, uses the registervariable again. The uses in block four 208 and block two 204 areidentical.

[0085] Following the method outlined in FIG. 11, the use of the variablein block two 204 can be removed from the loop and combined with thedefinition of the register value in first block 202. Similarly, the useof the register in block four 208 can be combined with the definition ofthe register in block three 206. The result removes the use of theregister variable from the blocks after the loop and allows thetranslation of the code.

[0086]FIG. 13 is a flow diagram illustrating loop peeling for the methodof FIG. 8. The method begins at decisional step 216 in which it isdetermined if the use of the register is atomized. That is, in somecases an opcode represents multiple commands and are not atomized. Ifuse of the register is not atomized, the No branch of decisional step216 leads to step 218. The use is internally atomized in step 218 andexecution continues at step 220. If use of the register is atomized, theYes branch of decisional step 216 leads to step 220. In step 220, theloop count is decreased by one. In step 224, one instance of the loopbody is copied to immediately follow the loop. Then, in step 226unnecessary definitions of the register can be eliminated.

[0087]FIG. 14 is an exemplary diagram of loop peeling as described inconjunction with FIG. 13. Illustrated are four basic blocks. First block202 contains a definition for the variable to be stored in theuntranslatable register (e.g. one that does not exist in the targetmachine). Second block 204 contains a use of the variable, while thirdblock 206 contains another definition. There is no use of the registerin fourth block 208, or what is known as the tail-end block. To peel,the loop count is decreased by one, and a copy of the interior loop iscopied immediately after the end of the interior loop block 206, forminga new block 204′ and a new block 206′. Now, the structure is incondition for loop rotation. The bottom two blocks are fourth box 208which is blank and new block 206′ which contains a definition of theregister. Fourth box 208 is blank since it contains no instance of theuntranslatable register. The definition in new block 206′ may not beneeded any more, and, if so, may be removed. Thus, these blocks can beeliminated. This leaves two basic blocks with no instances of theuntranslatable register, and the two blocks may now be ignored forpurposes of this transformation or optimization. This results in astructure having a definition in first block 202, a use of the variablein second block 204, a definition in third block 206 and a use in fourthblock 204. This structure is similar to that in FIG. 12 which we alreadydetermined to be able to undergo loop rotation. Such a loop rotation isillustrated on the right-hand portion of FIG. 14.

[0088]FIG. 15 is a detailed block diagram illustrating details of thesource and translation files 24 and 28 in the display processor 50. Aspreviously described, the display processor 50 generates a display ofthe source and translation files 24 and 28 that is output to thegraphical user interface 16. In the display, corresponding groups ofelements in the source and translation files 24 and 28 are aligned,source and corresponding translation instructions are associated witheach other, and the source and translation files 24 and 28 are displayedside-by-side. Accordingly, an intuitive display is provided by which theuser is able to efficiently review, modify, and save a translation.

[0089] Referring to FIG. 15, a source file 414 includes a plurality ofsource elements 422. This source file 414 is an internal representationof the source file 24 in section order. A translation file 418 includesa plurality of translation elements 426 corresponding to the sourceelements 422. In one embodiment, the translation file 418 is theintermediate translation file generated by the transformer 48 and passedto the display processor 50.

[0090] The source and translation elements 422 and 426 in the source andtranslation files 414 and 418 are associated with each other throughtranslation 430, source 434, order 438, family 442, and nullrelationships 446. The relationships are generated by the translator 46and are stored by pointers from and to the related elements 422 and 426.Exemplary source and translation elements s₁-s₈ and t₁-t₈ will be usedin conjunction with FIG. 15 to explain the different relations and inconjunction with FIGS. 16-19 to explain operation of the displayprocessor 50.

[0091] The translation relationships 430 each represent a relationshipfrom the source element 422 to the corresponding translation elements426 that were generated from the source element 422. Thus, one or moretranslation elements 426 may be generated from each source element 422.In one embodiment, the translation relationships 430 are stored by apointer from the original source element 422 to the first correspondingtranslation element 426 that was generated from the source element 422.In this embodiment, as described in more detail below, the remainingtranslation elements 426 are associated with the first translationelement 426 via the family relationship 442. For example, source elements, is related to translation element t₂ via the translation relationship430.

[0092] The source relationship 434 relates the translation element 426to the source element 422 which generated the translation element 426.Since more than one translation element 426 may be generated from asingle source element 422, a plurality of translation relationships 430may refer to a single source element 422. For example, translationelements t₄ and t₅ have the source relationship 434 to source elements₅.

[0093] The order relationship 438 represents the relationship betweentwo elements in the file. A next order relation 438 a represents arelationship from an element to a following element. For example, thenext order relationship 438 a exists between source element s₂ andsource element s₃. A previous order relationship 438 b represents arelationship from an element to a preceding element. For example, theprevious order relationship 438 b exists between the translation elementt₃ and the translation element t₂.

[0094] The family relationship 442 exists between the translationelements 426 and represents that the family related 442 translationelements 426 were generated from the same source element 422. Forexample, the family relationship 442 between the translation element t₄and the translation element t₅ shows that both were generated from thesame source element s₅.

[0095] The null relationship 446 represents the lack of a relationship.The null relationship 446 typically occurs when an instruction is notneeded on a target device. For example, the source element s₄ did notgenerate any translation elements 426, thus, the source element s₄ hasthe null relation 446.

[0096] The relationships between the source and translation elements 422and 426 are used by the display processor 50 to partition the source andtranslation files 414 and 418 into a plurality of partitions 458. Eachpartition 458 has a group of source elements 452 and a group of alltranslation elements 456 corresponding to the group of source elements452. As described in more detail below, the partitions 458 allowcorresponding groups of source and translation elements 452 and 456 tobe aligned for display to the user.

[0097] As shown in FIG. 15 a plurality of partition boundaries 454delimit the plurality of partitions 458. The partitions 458 are each aminimal length sequence of elements such that the partition boundary 454does not cross the translation 430 or source relationships 434. Statedanother way, the partition 458 contains the minimum number of elementssuch that no included source element 422 or translation element 426contains a source 434, translation 430, or family 442 related element inanother partition 458.

[0098] In one embodiment, the source and translation elements 422 and426 are partitioned by first determining a source start element in thesource file 414. The source start element is determined by picking thefirst source element following the last source element in the previouspartition 458. If no previous partition 458 has been delimited, forexample, when the method is first starting, the first source element ischosen as the source start element.

[0099] A translation start element is then determined in the translationfile 418. The translation start element is determined by picking thefirst translation element following the last translation element in theprevious partition 458. If no previous partition 458 has been delimited,for example, when the method is first starting, the first translationelement is chosen as the translation start element.

[0100] A translation stop element is next determined. The translationstop element is determined by choosing the last element in thetranslation start element's family. If the translation start element hasno family relations 442, thus being the only element in the family, thenthe translation stop element is chosen to be the translation startelement.

[0101] The translation stop element is then updated based on the lastelement in the family of each translation element between thetranslation start and stop elements. If a member of the family of thetranslation elements between the translation start and stop elementsoccurs later in the file than the current translation stop element, thenthe translation stop element is updated to be that later translationelement. If the translation stop element changes the updating process isrepeated to check that no translation element between the translationstart element and the new translation stop element has a family memberlater than the new translation stop element.

[0102] A source stop element is then determined and updated based on thesource stop element's corresponding translation elements. The sourcestop element is initially set to be the current source start element. Ifthe source stop element has corresponding translation elements betweenthe translation start and stop elements, the source stop element'scorresponding translation element's family is checked. If the sourcestop element's corresponding translation element's family includes amember that occurs after the translation stop element, the translationstop element is updated to the last member of the source stop element'scorresponding translation element's family. The source stop element isthen updated to be the next source element in the source file and themethod repeats.

[0103] If the source stop element's corresponding translation element isoutside the translation start and stop elements, s then the partition458 has been found. The found partition 458 is delimited by the endingpositions of the source and translation start and stop elements. Thesource and translation start elements delimit the beginning of thepartition 458. The source and translation stop elements delimit the endof the partition 458. The process is repeated until the end of thesource and translation files 414 and 418 is reached. At this point, thefiles 414 and 418 are fully partitioned into groups that can be alignedfor display.

[0104] FIGS. 16-18 are a series of block diagrams illustrating detailsof the display processor 50 for generating a display for the source andtranslation files 414 and 418. Referring to FIG. 16, a correspondencemap 450 is provided as a tool for aligning the corresponding groups ofsource and translation elements 452 and 456. The correspondence map 450includes a plurality of pairs of source and translation groups 452 and456. Each group includes source and translation elements 422 and 426that are to be aligned. The correspondence map 450 also includes logicaldivisions at the partition boundaries 454.

[0105] In operation, the correspondence map 450 is builtpartition-by-partition 458. In one embodiment, the source instructionelements 422 and translation instruction elements 426 included withinthe groups 452 and 456 are aligned in the correspondence map 450 in sucha way that the distance between corresponding source and translationinstruction elements, 422 and 426, is minimized while maintainingoriginal source and translation order. In this embodiment, minimaldistance does not require the related source instruction elements 422and translation instruction elements 426 be adjacent to or horizontallyaligned with each other. The distance minimization heuristic maintainsthe correct order of both the source elements 422 and the translationelements 426. For example, the correspondence map 450 in FIG. 16 showssource element s₁ horizontally aligned with translation element t₁ eventhough source element s₁ actually generated the translation element t₂,as shown in FIG. 15. Once all the instruction elements in the partition458 have been added to the correspondence map 450, null elements 462 maybe added to the partition 458 to equalize the number of elements in thesource group 452 and the translation group 456 that the partition 458delimits. For example, the null elements 462 shown in FIG. 16 serve toequalize the number of instruction elements in the source group 452 andthe corresponding translation group 456 in two of the partitions 458.

[0106] Referring to FIG. 17, a source hash table 470 is used for theinsertion of comments and to provide for efficient storage and lookup ofsource display entries. The source hash table 470 contains a pluralityof buckets 474 and a plurality of hash entries 478. The buckets 474contain a plurality of hash next pointers 492. The number of buckets isdependent on a hash function. The source hash table 470 also contains asource display order thread 482. The source display order thread 482includes a source display order thread head 484 and a display orderthread next pointer 494 included within the hash entry 478. The hashentries 478 include a source line number 486, a display entry pointer488, the hash next pointer 492, and the display order thread nextpointer 494. The display entry pointer 488 refers to a display entry490. The source line number 486 is computed from the line number in thesource file 24 which is related to the information in the display entry490. The display entry 490 includes the text that is to be displayed forthe display entry 490 and the source line number 486. The hash nextpointer 492 refers to the next hash entry 478 in the bucket 474. Thedisplay order thread next pointer 494 refers to the next entry in thedisplay order thread for the hash table.

[0107] The source hash table 470 operates as follows. A correspondencemap line 466 (see FIG. 16) from the correspondence map 450 is received.The line 466 contains the source element 422 and the translation element426. The source element 422 is inserted into the source hash table 470,while the handling of the translation element 426 will be more fullydescribed in association with FIG. 18. To insert the source element 422into the source hash table 470 the display entry 490 is first createdfor the source element 422. If the display entry 490 is to be associatedwith the null element 462 then the display entry 490 will be replaced bythe null relation 446 (see FIG. 15). The display entry 490 includes theappropriate text to be displayed for the source element 422 and thesource line number 486 with which the source element 422 is associated.The display entry 490 is then associated with the display entry pointer488 in the hash entry 478. The hash entry 478 will also include thesource line number 486 with which the source element 422 is associated.

[0108] The hash entry 478 will then be inserted into the source hashtable 470 in the appropriate bucket 474. The appropriate bucket 474 isdetermined by the hash function. The hash function will map a key valueto a particular number. In the source hash table 470, the key for thehash function is the source line number 486 contained within the hashentry 478. The hash function shown in FIG. 17 takes the source linenumber 486 and computes modulo 5 on it. Module means to do integerdivision and return the remainder as the result. The result of thesource line number 486 modulo 5 is the appropriate bucket 474 for theinserted hash entry 478.

[0109] Inserting the hash entry 478 involves updating the appropriatehash next pointer 492. If the hash entry 478 is the first to be insertedinto the bucket 474, the hash next pointer included in the bucket 474 isupdated to be associated with the hash entry 478. If the hash entry 478is not the first to be inserted into the bucket 474, the hash nextpointer 492 of the previous hash entry 478 inserted in the bucket 474 isupdated to be associated with the inserted hash entry 478.

[0110] After the hash entry 478 is inserted into the appropriate bucket474, the source display order thread 482 is updated. If the hash entry478 is the first hash entry 478 to be inserted into the source hashtable 470, the source display order thread head 484 is associated withthe hash entry 478. If the hash entry 478 is not the first hash entry478 to be inserted into the source hash table 470, then the displayorder thread next pointer 494 of the previously inserted hash entry 478is associated with the hash entry 478. The source display order thread482 tracks the proper order that the display entries 490 are to bedisplayed in for the source elements 422. The source display orderthread 482 allows the source elements 422 to be displayed in properorder regardless of the location of the display entry's 490 associatedhash entry 478. This process is performed for every correspondence mapline 466.

[0111] Referring to FIG. 18, a translation hash table 500 is used forthe insertion of comments and to provide for efficient storage andlookup of translation display entries. The operation of the translationhash table 500 is substantially similar to the operation of the sourcehash table 470 except that the display entries 490 are created from thetranslation elements 426. The display entries 490 and hash entries 478of the translation hash table 500 use as the source line number 486 theline number of the source element 422 that generated the translationelement 426 associated with the display entry 490. The translationdisplay order thread 502 allows the translation elements to be displayedin proper order regardless of the location of the display entry's 490associated hash entry 478.

[0112]FIGS. 19A and 19B are a flow diagram illustrating a method forgenerating a display in the display processor 50. Referring to FIG. 19A,the method begins at step 610 in which the source file 414 and thetranslation file 418 are received by the display processor 50. Aspreviously described, the source file 414 is received from the front end40 and the translation file 418 is received from the transformer 48. Thesource and translation files 414 and 418 are section ordered and alreadyhave the translation relationships 430, source relationships 434, orderrelationships 438, family relationships 442, and null relationships 446established.

[0113] Proceeding to step 614, the source and translation files 414 and418 are partitioned into the plurality of partitions 458. Each partition458 has a group of source elements 422 and a group of all translationelements 426 corresponding to the group of source elements 422.

[0114] Next, at step 618, the correspondence map 450 is generated. Inone embodiment, the correspondence map 450 is generated by inserting allthe instruction elements of a given partition 458 such that the distancebetween the related instruction elements is minimized. The relatedinstruction elements are any source instruction elements 422 ortranslation instruction elements 426 that contain any of therelationships, except the null relationship 446, between them. Theminimum distance heuristic preserves the order of the instructionelements as they appeared in the files. Thus, as instruction elementsare inserted into the correspondence map 450 the source instructionelements 422 may not line up horizontally with the source instructionelement's 422 related translation instruction elements 426.

[0115] Next, at step 622, null elements 462 are inserted to equalize thenumber of elements in the partitions 458 of the source and translationgroups 452 and 456 of the correspondence map 450. While inserting nullelements 462 an effort is made to align source elements 422 with relatedtranslation elements 426. Again, source elements 422 and relatedtranslation elements 426 may not align exactly.

[0116] Then, at step 624, a hash table loop is entered which includessteps 624, 628, 632, 636, 640, 644, and 648. The loop begins at step 624with the display processor 50 receiving the correspondence map line 466.If this is the first iteration of the loop, the correspondence map line466 received is the first line of the correspondence map 450. Otherwise,it is the line immediately following the correspondence map line 466that has just been handled. Each correspondence map line 466 includes ahorizontally aligned pair of source elements 422 and translationelements 426. Next, at step 628, display entries 490 are created for thesource element 422 and the translation element 426 in the correspondencemap line 466 received at step 624. The display entry 490 for the sourceelement 422 is then inserted into the source hash table 470 at step 632.At step 636 the source hash table display order thread 482 is updated asdescribed previously with reference to FIG. 17.

[0117] Next, at step 640, the display entry 490 created for thetranslation element 426 is associated with the display entry pointer 488included within the hash entry 478 that the display entry 490 isassociated with. The hash entry 478 is then inserted in the appropriatebucket 474 in the translation hash table 500.

[0118] Then, at step 644, the translation hash table display orderthread 502 is updated. The operation of the translation hash tabledisplay order thread 502 is similar to the operation of the source hashtable display order thread 482 and operates in the manner previouslydescribed with reference to FIG. 18.

[0119] Proceeding to decisional step 648, the display processor 50determines if further correspondence map lines 466 are to be insertedinto the hash tables 470 and 500. If more correspondence map lines 466need to be handled, the Yes branch of decisional step 648 returns tostep 624 and receives the next correspondence map line 466. If no morecorrespondence map lines 466 need to be inserted, the No branch ofdecisional step 648 exits the hash table loop and proceeds to step 652.

[0120] At step 652, a comment insertion loop including steps 652, 656,660, 664, 668, 672, 676, and 680 is entered. In step 652 a line from thesource file 414 is received. The line from the source file 414 willinclude either an instruction or comment. At decisional step 656, acheck is made on the line, and if the line includes a comment, then adisplay entry 490 is created for the comment at step 660. The displayentry 490 is then buffered at step 660 and a loop back to step 652occurs where the next line from the source file 414 is received. If thesource file line does not include a comment, it includes an instructionand the method continues on to step 664. The decisional step 656 mayhave additional determinations to handle a variety of differing types ofelements.

[0121] Next, at step 664, the display entries 490 that were buffered atstep 660, if any, are inserted into the source hash table 470. Theinstruction line from the source file 414 that moved the method fromstep 656 to step 664 has an associated line number that is the sourceline 486 used in creating the hash entries 478 for the buffered displayentries at step 660. The source hash table display order thread 482 isthen updated at step 668. The result of the buffering at step 660, theinsertion at step 664, and the update at step 668 is that the commentsthat were buffered at step 660 have been keyed to the line number of thesource element 422 that the comments precede. Thus resulting in thedisplay of the comments associated with the source element 422 justprior to the display of the source element 422.

[0122] Then, at step 672, the display entries buffered at step 660 areinserted into the translation hash table 500. The hash entries 478created for inserting the comments into the translation hash table 500use as the source line number 486 the line number of the instructionthat transitioned the method from step 656 to step 664. Then, at step676, the translation hash table display order thread 502 is updated. Thetranslation hash table display order thread 502 is updated in such amanner as to place the hash entries 478 including display entries 490for the comments buffered in step 660 prior to the hash entry 478associated with the display entry 490 for the translation element 426generated from the source element 422. Thus, the comments associatedwith the instruction in the source file 414 are displayed just prior tothe translation element 426 that the source instruction generated.Because an equal number of comment lines are added to each of the hashtables 470 and 500, the corresponding group of source and translationelements remain aligned.

[0123] Next, at decisional step 680, the buffer utilized in step 660 isreset. Then, a check is made to see if there are more lines to bechecked in the source file 414. If lines remain in the source file 414that need to be checked, the Yes branch of decisional step 680 returnsto step 652 and the next source file line is received. If there are nomore lines remaining in the source file 414 to be checked for comments,the No branch of the decisional step 680 proceeds to step 684 and exitsthe comment insertion loop.

[0124] Referring now to FIG. 19B, at step 684, a display partners loopincluding step 684, 688, 696 and 700 is entered. Steps 684 and 688represent a lock-step traversal of the source and translation hash tabledisplay order threads 482 and 502. The lock-step traversal represents anentry-by-entry traversal of the display order threads 482 and 502 usingthe hash entries 478 to find successive lines. As shown in steps 684 and688, when the next hash entry 478 is stepped to in the source hash table470, the next hash entry 478 is stepped to in the translation hash table500.

[0125] Next, at step 696, the source and translation hash entries 478are inserted into a display partners list 514. The display partners list514 is a list of pairs of display entries 490 that are meant to bedisplayed on the same line. There will be an entry in the displaypartners list 514 for every pair of display entries 490. The pair ofdisplay entries 490 include one display entry 490 from the source hashtable 470 and one display entry from the translation hash table 500.

[0126] Then, at decisional step 700, a check is made to see if there areany further display entries 490 in the source and translation hash tabledisplay order threads 482 and 502. If further display entries 490 exist,then the Yes branch of decisional step 700 returns to step 684 and thenext entry in the source and translation hash table display orderthreads 482 and 502 are added to the display partners list. If no moredisplay entries 490 are in the threads 482 and 502, the No branch ofdecisional step 700 exits the display partners loop and proceeds to step704.

[0127] At step 704, the source file 414 is opened at its beginning.Then, at step 708, the line number of the next line in the source file414 is received and a display line list loop including steps 708, 712,716, 720, and 724 is entered. If the source file 414 has just beenopened in step 704 then the next line number is the first line number inthe source file 414. If the source file has not just been opened at step704 then the next line number is the line number immediately followingthe line number that was just handled.

[0128] Proceeding to step 712, the line number received from the sourcefile 414 and step 708 is used to find the display entries 490 associatedwith that line number in the source hash table 470. Once the pluralityof display entries 490 associated with the line number have been foundin the source hash table 470, the display pairs for those displayentries 490 are found in the display partners list 514 at step 716.

[0129] Next, at step 720, the display entries 490 found at step 712 and716 are added to a display line list 518. The display line list 518 iscreated to facilitate the display of source and translation elements 422and 426 in source file order as opposed to section order. When the frontend 40 originally parsed the source file 414 the source elements 422were ordered by section. However, in one embodiment, a goal is todisplay the source and translation elements 422 and 426 in an orderdictated by the order of the source instructions found in theunsectioned source file, thus, the display is reordered from the sectionbased order to the unsectioned order. Then, at decisional step 724, acheck is made to see if the end of the unsectioned source file has beenreached. If the end of the unsectioned source file has not been reached,and further lines need to be handled from the source file, the No branchof decisional step 724 returns to step 708 and the next line number isreceived from the unsectioned source file. If the end of the unsectionedsource file has been reached then the Yes branch of decisional step 724exits the display line loop and proceeds to step 728.

[0130] At step 728, the display line list 518 is passed to the graphicaluser interface 16 for display to the user. As previously described, thedisplay processor 50 generates a display of the source and translationfiles 24 and 28 that is output to the graphical user interface 16. Inthe display, corresponding groups of elements in the source andtranslation files 24 and 28 are aligned, source and correspondingtranslation instructions are associated with each other, and source andtranslation files 24 and 28 are displayed side-by-side, as illustratedin FIG. 3. Accordingly, an intuitive display is provided by which theuser is able to efficiently review, modify and save a translation.

[0131]FIG. 20 is a flow diagram illustrating a method for translatinginclude files 26 accessed by the source file 24. As previouslydescribed, an include file 26 typically includes code to perform (orperforms) an operation used by a number of files and is therefore mostefficiently programmed as a separate file that can be used or called byany number of files.

[0132] Referring to FIG. 20, the method begins at step 814 in which asource include file 26 is received from the graphical user interface 16.The source include file 26 is received upon selection of the sourceinclude file 26 by the user or other suitable event.

[0133] Proceeding to step 830, the source include file 26 is translatedinto the translation include file 30. The source include file 26 istranslated by the translation tool 14 as previously described inconnection with the source file 24. Accordingly, the source include file26 is parsed by the front end 40 and then analyzed and translated by theback end 42.

[0134] Then, at step 832, in the back end 42, the display processor 50generates a display similar to that for the source and translation files24 and 28. Accordingly, corresponding groups of elements in the sourceand translation include files 26 and 30 are aligned, correspondinginstructions are associated with each other, and the source andtranslation files are displayed side-by-side. In addition, problematicor other elements to be reviewed by the user are indicated with thestatus icons and listed in an output window.

[0135] Next, at state 834, the source and translation include files 26and 30 are displayed by the graphical user interface 16 for review andmodification by the user. In response to user modifications received bythe graphical user interface 16, state 834 returns to step 830 in whichthe source elements are reanalyzed and retranslated based on the usermodification.

[0136] After the user has performed all of the user's desiredmanipulations on the displayed information, state 834 leads to step 838.The translated version of the source include file 26 is saved as thetranslation include file 30. The translation include file 30 includesthe plurality of translation elements 426 corresponding to the elementsin the source include file 26. A translation include file name isspecified by the user when the translation include file 30 is saved orotherwise associated with the translation include file 30.

[0137] Proceeding to step 850, the translation include file namespecified by the user in step 838 is propagated back to the graphicaluser interface 16. The translation include file name is incorporatedinto the translation file 28 as the include file in the translation file28 associated with the source include file name in the source file 24.

[0138] Thus, it may be seen that the present invention provides atranslation system having a front end 40 and a back end 42. The frontend 40 identifies source elements in a source file 24. The back end 42generates a translation file 28 having translation elementscorresponding to translation of the source elements and has an interfacefor receiving inputs for modifying said translation.

[0139] Although the present invention has been described using severalembodiments, various changes and modifications may be suggested to oneskilled in the art after a review of this description. It is intendedthat the present invention encompass such changes and modifications asfall within the scope of the appended claims.

What is claimed is:
 1. A translation system, comprising: a front end foridentifying source elements in a source file; and a back end forgenerating a translation file having translation elements correspondingto translation of said identified source elements and having aninterface for receiving inputs for modifying said translation.
 2. Thesystem of claim 1, wherein the source file is for a source device andthe translation file is for a disparate target device.
 3. The system ofclaim 11 wherein the source file is a linear assembly file for a targetdevice and the translation file is a scheduled assembly file for thatdevice.
 4. The system of claim 1, wherein the source file is an assemblylanguage file.
 5. The system of claim 4, wherein the translation file isan assembly language file.
 6. The system of claim 1, wherein saidtranslation is a context-dependent translation based on static analysisof the source file.
 7. The system of claim 1, wherein the back endfurther comprises: a translator for performing a context-dependenttranslation, the translator comprising: a translation machinedescription for mapping source opcodes to target opcodes; a sourcemachine description containing a description of source opcodes andsource operands in a generic representation; a target machinedescription containing a description of target opcodes and targetoperands in a generic representation; and wherein the translatorreceives a source instruction from said front end, utilizes thetranslation machine description and source machine description andtarget machine description to translate source elements into targetelements.
 8. The system of claim 7, wherein the proper target opcode ischosen from a group of potential target opcodes by comparing the targetopcode and target operand with the source opcode and source operand. 9.The system of claim 7, wherein two or more source opcodes can becombined to a single target opcode when there is a target opcode thatrepresents the two or more source code opcodes.
 10. The system of claim1, wherein the user interface is a graphical user interface.
 11. Thesystem of claim 10, wherein the graphical user interface displays atleast a portion of the source elements in a source window, at least aportion of the translation elements in a translation window, and thesource and translation windows are displayed side-by-side.
 12. Thesystem of claim 11, wherein corresponding groups of elements of thesource and translation files are aligned in the source and translationwindows.
 13. The system of claim 11, wherein at least one of the sourceand translation windows is operable to display a status icon for anelement in the window.
 14. A method for performing translationcomprising: receiving a source file; identifying source elements in thesource file; generating a translation file having translation elementsby performing a context-dependent translation of the source elements;displaying the translation elements in an interface for receiving userinputs; and in response to user inputs, automatically regeneratingselected translation elements based on the user inputs.
 15. The methodof claim 14, wherein the source file is for a source device and thetranslation file is for a disparate target device.
 16. The method ofclaim 14, wherein the source file is a linear assembly file for a targetdevice and the translation file is a scheduled assembly file for saidtarget device.
 17. The method of claim 14, wherein the source file is anassembly language file.
 18. The method of claim 17, wherein thetranslation file is an assembly language file.
 19. The method of claim14, further comprising: performing static analysis of the sourceelements in the source file; and performing context-dependenttranslation of the source elements based on the static analysis.
 20. Themethod of claim 14, wherein the step of generating a translation filefurther comprises: converting an opcode of a source machine to an opcodeof a translation machine file by comparing the source opcode to possibletranslation opcodes; converting the operand of the source opcode bycomparing an operand of the source opcode in a generic expression with ageneric expression for a translation operand; combining the translationopcode and the translation operand to form a translation.
 21. The methodof claim 20, wherein the step of converting an opcode of the source filefurther comprises choosing a translation opcode from a group ofpotential translation opcodes by comparing the translation opcode andtranslation operand with the source opcode and source operand.
 22. Themethod of claim 20, wherein the step of converting the source opcodefurther comprises the step of combining two or more source opcodes intoa single translation opcode when there is a translation opcode thatrepresents the two or more source opcodes.
 23. The method of claim 14,wherein the user interface is a graphical user interface.
 24. The methodof claim 23, further comprising: displaying the source elements in asource window; displaying the translation elements in a translationwindow; and displaying the source and translation windows side-by-sidein the graphical user interface.
 25. The method of claim 24, furthercomprising aligning corresponding groups of elements of the source andtranslation files in the source and translation windows.
 26. The methodof claim 24, further comprising displaying a status icon for an elementin at least one of the source and translation windows.
 27. A translationsystem, comprising: a computer capable of executing a program, and aninteractive program for translating code for a first processor into codefor a second processor and capable of being executed on said computer.